1. Field of the Invention
This invention relates to transmission management systems and methods of operation. More particularly, the invention relates to a telecommunications management network system and method for mapping a multi-threaded persistent agent management information base to a configurable data base to store managed objects, attributes and internal implementation details.
2. Description of Prior Art
In the Telecommunication Management Network (xe2x80x9cTMNxe2x80x9d) framework within the Open System Interconnection (xe2x80x9cOSIxe2x80x9d) Environment (xe2x80x9cOSIExe2x80x9d), a TMN agent can make management information available to a TMN manager. Normally, TMN agents make management information available by providing an open common management information protocol (xe2x80x9cCMIPxe2x80x9d) interface to TMN managers. The information that the TMN agent provides is contained in a logical database called a Management Information Base (xe2x80x9cMIBxe2x80x9d).
A MIB contains a hierarchy of managed object instances. The object class characteristics of these managed object instances are described according to guidelines for the definition of managed objects (xe2x80x9cGDMOxe2x80x9d), an object-oriented specification language. The externally observable data values of managed object instances are contained in attributes. The Abstract Syntax Notation One (xe2x80x9cASN.1xe2x80x9d) industry standard is used to define the data types for these attributes.
Currently GDMO/ASN.1 is mapped only to SQL data definition language (xe2x80x9cDDLxe2x80x9d). These mappings are fixed format and not configurable. For example, the mapping from GDMO classes and attributes, and the attributes ASN.1 types, is not configurable for different managed agent processes. Moreover, the structured query language (xe2x80x9cSQLxe2x80x9d) database language is the only supported target database language. Existing solutions comply with the industry specifications that define the development environment and result in non-configurable mapping.
Thus, existing solutions do not provide configurable runtime environments, or persistent managed agent functions, such as CMIP request mapping, managed object instance (xe2x80x9cMOIxe2x80x9d) caching, or multi-threading. Further, current solutions do not support both domestic and international data structures.
The TMN/OSI framework standardizes managed object class definitions, their attributes, and data types that TMN agents make visible at the CMIP interface. These standards fail to disclose how the TMN agents are implemented. For example, it would be beneficial for the TMN agent to have additional internal variables available in the agents themselves, and user defined data available in the managed objects. These internal variables are related to the standard behavior of TMN agents. The user-defined data is not necessarily related to the standard behavior of the TMN agents, and may contain any implementation-specific data which is needed. Neither the internal variables nor the user-defined data is visible at the CMIP interface.
It is therefore desirable to have a configurable mapping that supports a variety of database languages, and which allows for the extension of the managed objects in the TMN agents to contain internal variables, and user defined data. Existing systems fail to provide a method for rapidly recovering from an agent process termination. Thus, it is desirable to have a persistent MIB that can be used to rapidly restart the terminated agent process.
An object of this invention is a multi-threaded persistent TMN agent, which supports configurable database schema mapping.
Another object is storing externally visible data, including managed objects and attributes, and internal variables and user defined data in a configurable and database-independent method.
These and other objects, features and advantages are achieved in a TMN system which includes persistent Management Information Bases (MIBs), configurable database schema mappings, database independent commands, and multithreaded message processing. The MIB is maintained in a general purpose database management system in secondary storage such as a hard disk and not by a TMN agent in main memory. Making the TMN MIB persistent requires both a static and a dynamic solution. With a persistent MIB, agent restart is faster. The MIB includes TMN managed object data. CMIP interface data, internal variables, and user defined data. The CMIP interface data pertains to the TMN managed objects and can include a distinguished name, object class, name binding, and attribute values for each TMN managed object. Internal variables can include xe2x80x9cnext notification identifierxe2x80x9d and xe2x80x9cpackages information.xe2x80x9d Both CMIP interface data and Internal variables are defined in the standards. User defined data can include any information which a user may require for the the implementation. A GDMO/ASN.1 to Database Data Definition Language (xe2x80x9cDDLxe2x80x9d) mapping is defined at development time. At run-time, incoming TMN manager operations are translated into Database Data Manipulation Language (DML, e.g. SQL DML) commands. Moreover, non-TMN data structures used to implement behaviors of the Managed Objects are supported. The MIB to database mapping supports any database language. The MIB is persistent because a persistent MIB continues to exist even after an agent process supporting the MIB is terminated. The agent process can terminate due to a system failure or other abnormal event. In such a case the object instances and their data, stored in the MIB, are saved in secondary memory so that they are not lost. The restarted managed agent process reflects the MIB state of the terminated managed agent process. The managed agent process allows xe2x80x9cMulti-threadedxe2x80x9d means or parallel processing of messages, including CMIP requests, received from manager processes.